職務機能のAWS 管理ポリシーから昔を振り返る

こんにちは、ゲストブロガーの佐々木拓郎（@dkfj）です。ひょんなことからDevelopers.IOに投稿させて頂けることになりました。普段は、SIerに勤務する傍らAWS本の執筆や技術同人誌を書いています。今日は、小ネタにAWSの歴史を絡めて、職務機能のAWS管理ポリシーを紹介したいと思います。

目次

• 目次
• IAMポリシーでジョブ機能（職務機能のAWS管理ポリシー）
• 職務機能のユースケースもといAWS管理ポリシーの制限
• NetworkAdministratorから読み解くAWSの歴史
• 明かされる真実

IAMポリシーでジョブ機能（職務機能のAWS管理ポリシー）

IAMポリシーの選択時にフィルターのポリシータイプに出てくるジョブ機能をご存知でしょうか？

このジョブ機能は、職務機能のAWS管理ポリシーと呼ばれるもので、特定の役割の人向けに用意されているAWS管理ポリシーです。ほとんどのAWS管理ポリシーは、EC2やLambdaなど機能ベースで作られているのですが、この職務機能のAWS管理ポリシーは利用者の役割（ロール）を想定して作られています。全部で10個存在します。

• 管理者
• Billing (料金)
• データベース管理者
• データサイエンティスト
• 開発者パワーユーザー
• ネットワーク管理者
• セキュリティ監査人
• サポートユーザー
• システム管理者
• 閲覧専用ユーザー

管理者（AdministratorAccess）や開発者パワーユーザー（PowerUserAccess）など比較的馴染みの多いものがありますが、これも実は職務機能のAWS管理ポリシーです。

職務機能のユースケースもといAWS管理ポリシーの制限

ではこの職務機能のAWS管理ポリシーのユースケースは、どのような場合なのでしょうか？中身を見てみると、他の管理ポリシーと同様に、用途別に必用な権限が羅列されているだけのように見えます。それであれば、自前でカスタマー管理ポリシーとして作ってもいいのではないでしょうか？職務機能のAWS管理ポリシーの特徴と利点が、次の2つになります。

• AWSの機能拡張に応じて、ポリシーもメンテナンスされていく
• IAMの文字数制限と無縁

AWSの機能拡張に応じて、ポリシーもメンテナンスされていく

まず1つ目の『AWSの機能拡張に応じて、ポリシーもメンテナンスされていく』についてです。これは通常のAWS管理ポリシーも同様なのですが、AWSの関連サービス・アクションが増えた場合、それに対応するAWS管理ポリシーも対応するサービスやアクションが増えていきます。一番顕著な例ですと、ReadOnlyAccess ポリシーですと全てのサービスに対してListやGet、あるいはDescribeの権限が付けられています。その実装としては、次のようにサービス名:List*などのような形で、ひたすらサービス名ごとに記載されています。

"applicationinsights:Describe*",
"applicationinsights:List*",
"appmesh:Describe*",
"appmesh:List*",

このサービス名のところにワイルドカード（*）を許してくれよという気はしますが、現状のIAMの仕様ではサービス名にワイルドカードは許可されません。よって、このようにサービスが追加される度にメンテナンスをしていく必用があります。AWSのサービスがどんどん出ている現状では、このメンテナンスに労力を割くのは現実的ではないので、AWS管理ポリシーを利用します。一般的には、ReadOnlyAccessポリシーを使うことが多いと思いますが、職務機能ポリシーの閲覧専用ユーザー（ViewOnlyAccess）があります。ただし、ReadOnlyAccessポリシーに比べると網羅率が低いです。

IAMの文字数制限と無縁

2つ目は、『IAMの文字数制限と無縁』という点です。AWSを使っているうちに、AWS管理ポリシーをコピーしてカスタマイズして使おうと思ったことがあるのではないでしょうか？そして、ReadOnlyAccessやネットワーク管理者（NetworkAdministrator）をコピーして保存しようとした瞬間に、次のような無慈悲なメッセージが表示されます。文字数制限の問題です。

IAMのカスタマー管理ポリシーは6,144文字まで、インラインポリシーは、ユーザーの場合は2,048文字など制限があります。一方で、AWSが作るAWS管理ポリシーは、無制限の模様です。これこそが、職能機能の管理ポリシーを使う理由の1つになります。

NetworkAdministratorから読み解くAWSの歴史

長い前置きですが、そろそろ本題です。AWSのアカウント管理をしている際に、開発者の特定の権限を禁止したい場合があります。その最たるものは、ほぼ管理者権限と同義であるIAMの権限です。それ以外に、ネットワークに関わる権限を取り除きたいというのもあるかと思います。しかし、このネットワークのアクセス権限を取り除くのが簡単なようで簡単ではないのです。なぜなら、AWSではネットワークの権限が、何故かVPCというサービスではなく、EC2の権限の中にまとめられているからです。そのため、EC2の必用な権限のみ与えるか、EC2のフルアクセスを与えた上でEC2にあるネットワーク関係の権限を拒否するという設計が必用です。初めてこの事実を知った人は、何でなんと思うことでしょう。ということで、歴史的な経緯を説明します。

原初、AWSのサービスはEC2とS3、その他少数のサービスで構成されていました。ネットワークを作る機能のVPCはなく、EC2はAWSのネットワークの海に島のようにポツンポツンと浮かび、セキュリティグループでのみ囲われている状態です。

今のLambdaに近いイメージでしょうか。このような形態は、EC2-Classicと呼ばれ、昔からのアカウントの人は今でも使えますが、最近作られたAWSアカウントでは利用できません。

その後にVPCの機能が作られ、今の一般的な利用形態になりました。VPCができて、サブネットやネットワークACLも利用可能になり、守られている感がでるようになっていますね。

という事で、当初はEC2とセキュリティグループでポートのイン／アウトの機能しかないところからスタートしているという経緯があります。ネットワークの機能がインスタンスに紐付くポートのIngress/EgressしかないのでEC2に属するのも、さもありなんという感じではあります。

明かされる真実

ここまで書きながら、改めてサービスリリースの年代と突き合わせてみました。

EC2　2006年
VPC　2009年
IAM　2010年

あれ、IAMよりVPCの方が先にあったぞ？ということは、IAMの設計段階で、EC2とVPCを分離する事は可能だったのでは？別けておいてくれれば、こんなに苦労することも無かったのにと思います。先を見越して設計するのは、AWSといえでも大変なんですねという話しかもしれません。もっともらしい事を書いていましたが、真相は藪の中ですが、個人的には少なからずEC2-Classicの影響はあるのではと考えています。

ということで、職務機能のAWS 管理ポリシーから振り返るAWSの小ネタでした。いかがでしたでしょうか？Developers.IOに慣れるまでは、しばらくはこのような小ネタを書いていこうかと考えています。また、この辺の小ネタをまとめて、AWSむかしばなしとして過去の経緯から現在のアーキテクチャを読み解くという技術同人誌を書いてみようかなと考えています。興味ある方は、ブックマークやSNSでコメントください。

以上、ゲストブロガーの佐々木拓郎（@dkfj）でした